$VER: RGFX-Chunks.doc 2.0 (28.8.2004) ===================================== A typical structure of a RGFX file (recommended) : FORM-RGFX RGHD Image Header RSCM Screenmode information RCOL Color and transparency information RBOD The Graphics itself Additional (optional) chunks should appear somewhere between RCOL and RBOD. Please refer to rgfx.h for the chunk specifications and allowed standard chunks. A few optional third party chunks are discussed in the following. These are not part of the format specification and should be considered private, proprietary extensions. RGFX - Optional chunks ---------------------- RXYA - Viewable XY-Area ----------------------- ** based on an idea by Peter Bornhall It may be useful to specify a small "view area" fromout a larger image, e.g. a 320x200 area inside a 2048x2048 image. struct RXYA { ULONG xy_LeftEdge; ULONG xy_TopEdge; ULONG xy_Width; ULONG xy_Height; }; RXXX - Image Rating ------------------- ** based on an idea by Peter Bornhall Not all images may be suitable for any group of recepients. struct RXXX { ULONG xxx_Rating; /* e.g. for parents who want to control access */ }; #define RXXX_HARMLESS (0L) /* this image won't affect anyone (e.g. cliparts) */ #define RXXX_PARENTAL_ADVISORY (1L) /* some people may feel offended by this (e.g. violent comics) */ #define RXXX_OFFENSIVE (2L) /* most people will feel offended by this (whatever) */ RALH - Alpha Channel Header (not with RGBA formats) --------------------------------------------------- ** based on an idea by Marcel Offermans ** not recommended for new implementations based on RGFX V2.0 or higher We support three different types of (late-added or separate) Alpha channels: - operating on a colormap (with upto 8 bit images only, and only, if MORE than one color should be transparent, i.e. when RCOL.rcol_TransColor does not suffice). Like with RCOL, the supplied table should be sized for 256 colors always, thus any unused entries should be set to zero (= fully transparent). - operating on separate pixels (with any bitdepth), supplying a width*height area of 0..255 values for each pixel (or component), where 0 means "fully transparent" and 255 means "not transparent at all" NOTE: this is the opposite as in PNG or in the ARGB formats (akl, 28.08.04) We also allow to differ between "complete" transparency and "color component specific" transparency, i.e. you either may apply the transparency to the whole RGB value of the color/pixel OR to each one of the RGB color components separately (which means 3 times as much data). This works with colormaps as well as pixelmaps. Examples: - transparent colormap, for whole color 256 entries, each one ranged 0..255 [ size: 256 bytes ] - transparent colormap, for color components 256 triple entries, means three sub entries ranged 0..255 (for R, G and B) [ size: 768 bytes ] - transparent pixelmap, for whole 8/24 Bit pixels x entries, each one ranged 0..255 [ size: width x height ] - transparent pixelmap, for RGB components 8/24 Bit pixels x entries, means each pixel with three sub entries ranged 0..255 (for R, G and B) [ size: width x height x 3 ] This may not be practical for most uses, since it will double the space needed for a 24 bit graphics and will need four times the space for a 8 bit graphics. struct RALH { ULONG ralh_AlphaType; /* the type of alpha channel - colormap (8 bit) */ /* or pixelmap (8/24 bit) */ ULONG ralh_TransparencyType; /* Completely or for a single component, only ? */ }; #define RALH_TYPE_PIXEL (0L) /* 8/24 bit: (non)transparacy value for each pixel */ #define RALH_TYPE_CMAP (1L) /* upto 8 Bit, only: supplies another colormap */ #define RALH_TRANS_ALL (0L) /* one 0.255 value for all components */ #define RALH_TRANS_COMPONENT (1L) /* one 0.255 value for each, separate component */